In a mobile communications system such as a cellular telecommunications system, some form of mobility management is required to handle a subscriber's geographical movement. Mobility management provides functionality to keep track of a subscriber so that he or she can be reached in the network regardless of their geographical location. It also ensures that a session is maintained during geographical movements and different load conditions, preferably in a manner that is seamless front eh end user's perspective.
FIG. 1 illustrates schematically a conventional 2G (GSM) system architecture. A Home Location Register (HLR) acts as a central database that contains details of each mobile phone subscriber that is authorized to use the GSM network, including subscribers' current locations; a Visitor Location Register (VLR) identity in the case of circuit switched access, and Serving GPRS Support Node (SGSN) identity in the case of packet switched access. When a subscriber attaches to the GPRS core network and a SGSN is allocated to the subscriber, the SGSN sends an Update Location request to the HLR (via the Gr interface) to cause the subscriber's profile within the HLR to be updated with the new location (SGSN identity). The SGSN maintains a knowledge of the current location of a subscriber.
FIG. 2 illustrates schematically a conventional 2G/3G system architecture, from which it will be appreciated that the SGSN and HLR of the 2G system are reused.
Work is ongoing within the Third Generation Partnership to specify a fourth generation mobile communication system architecture known as Long Term Evolution (LTE).
FIG. 3 illustrates the LTE system architecture, including an evolved UMTS Radio Access Network (e-UTRAN) and an Evolved Packet Core (EPC) network. Unlike the 3G architecture, LTE does not reuse either the HLR or the SGSN. Rather, a new mobility management entity node, the MME, is introduced into the e-UTRAN, whilst a Home Subscriber Server (HSS) replaces the functionality of the HLR in the EPC. The MME and the HSS communicate via the S6a interface. Like the SGSN, the MME maintains a knowledge of the current location of a subscriber on the cell level.
It is worthy of note here that the term HSS may also be used in the context of 2G/3G access, to indicate an HLR with added functionality, e.g. IP Multimedia Subsystem (IMS) functionality. However, for the purpose of the following discussion, the central subscriber database within the 2G/3G access is referred to as an “HLR”, whilst that within the LTE access is referred to as an “HSS”.
In order to allow LTE subscribers to make use of 2G/3G services (e.g. in geographic locations where LTE is not available), seamless mobility between the different technologies should be available. This requires inter-operability between the HLR and the HSS. This means that the target mobility management entity (that is the SGSN or MME to which the subscriber is to be handed over to) must be able to inform the HLR—in the case where the target entity is an SGSN—or the HSS—in the case where the target entity is an MME—of the change of user location by sending an Update Location to the HLR/HSS. Upon reception of Update Location, the HLR/HSS must send a Cancel Location to the old mobility management entity to cause the entity to delete the location entry for the subscriber in question. This is required in order to release the associated packed switched bearer in the old access network.
The HLR and HSS vertical solutions will likely evolve to an HLR and HSS built on a data layered architecture that separates data from application logic. This is illustrated schematically in FIG. 4. The HLR and HSS layered architecture provides centralisation of user and subscription data. The user and subscription data are stored in a back-end centralised user database (CUDB), with the front-end servers (HLR-S and HSS-S) supporting the application logic. The front-end servers are “dateless” configured and implement mechanisms to read the data from the back-end CUDB for service execution, and to update the CUDB with dynamic changes in the subscriber profiles arising for traffic reasons, e.g. user status, user location, or as a consequence of subscriber procedures initiated form a user terminal.
A function know as Idle mode Signalling Reduction (ISR), 3GPP TS 23.401, provides a mechanism to limit signalling during inter-radio access technology (inter-RAT) cell reselection (i.e. a handover between a 2G/3G RAT and a LTE RAT) in idle mode. Such a functionality is desirable as it is expected that, at least in the initial rollout phase, LTE access will be limited to relatively small “hot spots” and as such inter-RAT handovers will be frequent. Maintaining 2G/3G bearers for a relatively short period will consume fewer network resources than would performing frequent inter-RAT handovers.
Though the ISR solution is not fully settled, from the HLR/HSS perspective, ISR support means that a subscriber can be simultaneously registered at the HLR in respect of a given Rel-8 compliant SGSN and at the HSS in respect of a given MME. Rel-8 compliant SGSNs and MMEs are pre-configured with a knowledge of their support for ISR.
According to ISR, when the subscriber moves between RATs, he/she remains registered in both domains. When for example the subscriber moves from a Rel-8 SGSN to an MME, the MME sends an Update Location to the HSS indicating that ISR applies. Consequently, the HLR/HSS does not send a Cancel Location to the SGSN. When the user moves back to the Rel-8 SGSN and ISR applies, the SGSN does not send an Update GPRS Location to the HLR/HSS. Pre-Rel-8 SGSNs do not support ISR. In the case of a handover involving such a legacy SGSN, or a handover between SGSN or MMEs, the Cancel Location is still required. FIGS. 5 and 6 illustrate respectively signalling associated an inter-MME handover and an inter-SGSN handover.
It is expected that combined SGSN/MME entities will be introduced into networks to replace or supplement the separate SGSN/MME entities. In this case, where a subscriber is handed over from either the MME or the SGSN part to the other part of the combined entity, following the sending of an Update Location from the combined entity to the HLR/HSS, it will not be necessary for the HLR/HSS to return a Location Cancel to the entity as the entity is already aware of the handover.
Regardless of whether or not ISR applies, it is necessary for the HLR and the HSS to inter-work. However, no such procedures have been defined. Whilst the Gr or S6a interface could be re-used for this purpose, any such solution would likely result in a complex and inefficient network architecture, with unnecessary signalling and functionality being replicated in both entities.